6. (New) A method for reducing colormap flashing on a display system, the 
display system having a frame buffer which provides a single hardware 
colormap, the method comprising the steps of: 

intercepting a request from an application program for an allocation of 
a private colormap; 

transparently simulating the allocation of the private colormap using a 
default colormap; and 

determining whether a private color cell has been requested by the 
application program and writing said private color cell to the default colormap. 

REMARKS 

The amendment to the Figure 3 and the Specification correct 
typographical and labeling errors and do not introduce any new matter into the 
application. Specifically, the amendment to Figure 3 deletes some 
unnecessary element numbers while the amendment to the Specification 
adds element numbers in the description that are supported by the drawings. 

Support for claims 5 and 6 can be found, among other places, on page 
1 1 , line 17 to page 12, line 2 of the Specification. No new matter is introduced 
by the Amendment. Upon entry of the Amendment, claims 1-6 will be 
pending in the application. 

Objection to the Specification and Drawings 

Figures 2 and 3 are objected to for failing to comply with 37 C.F.R. 
1.84(p)(4). Applicant has amended Figure 3, and the Specification to correct 
the errors and requests that the objection to the drawings be withdrawn. In 
addition, the Applicant has amended the Specification to correct the error on 
page 9 and requests the objection to the Specification be withdrawn. 

Rejection of Claims under 35 U.S.C. § 102(b) 

Claims 1—4 are rejected under 35 U.S.C. § 102(b) over Aschenbrenner 
et a/ (U.S. Pat. No. 5,406,310). A rejection under 35 U.S.C. § 102(b) requires 
that "each and every element as set forth in the claim is found, either 
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expressly or inherently described, in a single prior art reference." See MPEP 
§ 2131 . Aschenbrenner does not meet this requirement because that 
invention does not transparently simulate the allocation of a private colormap 
requested from an application like the present invention. 

Claim 1 of the present invention includes the step of transparently 
simulating the allocation of the private colormap using a default colormap. 
See claim 1 , lines 7-8. This transparently simulating step fools the 
application program into believing that it has properly obtained a private 
colormap, when in actuality the default colormap is used. See Specification, 
page 10, lines 13-19. This transparent simulation does not force an 
application to decide whether to use substitute colors during the allocation of 
a private colormap. 

In contrast, Aschenbrenner teaches away from transparently simulating 
the allocation of the private colormap by forcing an application to choose 
among three alternatives for allocating the colors in the colormap used by the 
application program. See Aschenbrenner, column 4, lines 58-67. Instead of 
providing a transparent interaction between and application and a colormap, 
Aschenbrenner places an obstacle between them that adds both time and 
complexity to the allocation of a colormap by an application. Accordingly, the 
rejection of claim 1 under 35 U.S.C. §1 02(b) over Aschenbrenner is improper 
and should be withdrawn. 

The rejection of claim 2 under 35 U.S.C. § 102(b) over Aschenbrenner 
is improper for at least the same reasons as claim 1 , but there is more: The 
method of claim 2 includes a step of allocating a secondary lookup table that 
is nowhere found in Aschenbrenner, In the closest color set process 
described in Aschenbrenner, unloaded image colors requested by an 
application program are compared against the colors in the default table, but 
nothing similar to a secondary lookup table is mentioned. Accordingly 
Aschenbrenner lacks this element as well. 

Applicant does not believe that the rejection of claims 3 and 4 under 35 
U.S.C. § 102(b) over Aschenbrenner has been properly stated. The Office 
Action states that it would have been "obvious" to one of ordinary skill in the 
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art to implement the method of claims 1 and 2 as computer executable 
instructions stored on a computer-readable medium. Applicant notes that if 
the Office is rejecting claims 3 and 4 because they are obvious in light of the 
prior art, then a rejection under 35 U.S.C. § 102(b) is improper as a matter of 
law. 

Nonetheless, Applicant notes that claim 3 includes computer readable 
code devices that cause a computer to transparently simulate the allocation of 
a private colormap using the default colormap. Therefore like claim 1 , claim 3 
does not change the color information in the default colormap in contrast to 
what is described in Aschenbrenner. Accordingly, claims 3 and 4 are not 
anticipated by Aschenbrenner for at least the same reasons as claims 1 and 
2. 

In view of all of the above, the rejection of claims 1—4 under 35 U.S.C. 
§ 102(b) over Aschenbrenner is improper, and Applicant respectfully requests 
that it be withdrawn. 

Conclusion 

The references that were cited but not relied upon are believed to be 
no more pertinent than those references that were relied upon, and Applicants 
believe the pending claims are patentable over those references. In view of 
all of the above, claims 1—4 are believed to be allowable and the case in 
condition for allowance, which action is respectfully requested. Should the 
Examiner be of the opinion that a telephone conference would expedite the 
prosecution of this case, the Examiner is requested to contact Applicants' 
attorney at the telephone number listed below. 

No fee is believed to be required by this Response. Should any fees 
be required, please charge Deposit Account 50-1 123. Should any extension 
of time be required, please consider this a petition therefore and charge the 
required fee to Deposit Account 50-1 123. 
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Respectfully submitted, 



July 24, 2002 




Eugene J. Bernard, Reg. No. 42,320 
HOGAN & HARTSON LLP 
1200 17 th Street, Suite 1500 
Denver, Colorado 80202 
Telephone: (303) 454-2457 
Facsimile: (303) 899-7333 
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MARKED UP VERSION OF THE AMENDMENT 



IN THE SPECIFICATION 

On page 6, second paragraph, please amend the specification as follows: 

Fig. 2 shows a block diagram of a system incorporating one 
embodiment of the present invention. Masked software interface 10 creates 
and manages a secondary lookup-table 12, which maps to the default 
colormap 14 (Fig. 7) as will be described below. The software interface 10 
intercepts and processes graphical requests or calls from an application 
program 16 (i.e., an X client application) which involve private colormap 
allocations. The interface 10 uses the default colormap 14 to satisfy the 
private colormap requests of application 16, without switching out the default 
colormap 14 from the display hardware 1_8 (i.e., frame buffer). In this manner, 
the display hardware 18 maintains the default colormap 14 without switching 
to a private colormap, and therefore colormap flashing is prevented. 

On page 7, second paragraph, please amend the specification as follows: 

The operating environment in which the present invention is used 
encompasses a standalone computing system as well as a general distributed 
computing system. In the distributed computing system, general purpose 
computers, workstations, or personal computers are connected via 
communication links of various types in a client-server arrangement. 
Programs and data, many in the form of objects, are made available by 
various members of the system. Some of the elements of a standalone 
computer or a general purpose workstation are shown in Fig. 3, wherein a 
processor 21 is shown, having an input/output (I/O) section 22, a central 
processing unit (CPU) 23 and a memory section 24. The I/O section 22 is 
connected to a keyboard 25, a display unit 26, a disk storage unit 29, 30 and 
31, a CD-ROM drive unit 27, and a network 32. The CD-ROM unit 27 can 
read a CD-ROM medium 28 which typically contains programs [35] 45 and 
data. The computer program products containing mechanisms to effectuate 
the apparatus and methods of the present invention may reside in memory 
section 24, on the disk storage unit 29 or 31 , or on the CD-ROM 28 of such a 
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system. Examples of such systems include SPARC Systems offered by Sun 
Microsystems, Inc., personal computers offered by IBM Corporation and by 
other manufacturers of IBM compatible personal computers, and systems 
running UNIX operation systems such as SOLARIS and LINUX operating 
systems. 

On page 9, second paragraph please amend the specification as follows: 

As shown in Fig. 3, the present invention could be embodied within in 
application program 45 [35] operating within the computing system [20]. The 
application program 45 [35] could be accessed over network 32 by remote 
stations 33, or accessed locally by the CPU 23. The software interface 10 of 
the present invention ([shown in Fig. 1] shown in Fig. 2 ) could be stored within 
disc storage unit 29, the floppy disc 31 , or the CD-ROM medium 28. 
Alternatively, the software interface 10 could be stored remotely within the 
storage devices associated with remote computers 33. The location of the 
software interface and related files is a matter of choice dependent upon the 
particular implementation chosen, and does not limit the scope of the present 
invention. 
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